home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000003_owner-urn-ietf _Fri Nov 1 10:12:16 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27189 for urn-ietf-out; Fri, 1 Nov 1996 10:12:16 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27184 for <urn-ietf@services.bunyip.com>; Fri, 1 Nov 1996 10:12:14 -0500
  3. Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA05839  (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 10:12:11 -0500
  5. Message-Id: <9611011512.AA05839@mocha.bunyip.com>
  6. Received: by privateer.windrose.omaha.ne.us; Fri Nov  1 09:11 CST 1996
  7. From: "Ryan Moats" <jayhawk@ds.internic.net>
  8. To: "jayhawk@ds.internic.net" <jayhawk@ds.internic.net>,
  9.         "Martin J Duerst" <mduerst@ifi.unizh.ch>
  10. Cc: "urn-ietf@bunyip.com" <urn-ietf@bunyip.com>
  11. Date: Fri, 01 Nov 96 09:12:22 
  12. Priority: Normal
  13. X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE
  14. Mime-Version: 1.0
  15. Content-Type: text/plain; charset="us-ascii"
  16. Content-Transfer-Encoding: 7bit
  17. Subject: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft)
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: "Ryan Moats" <jayhawk@ds.internic.net>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. Sorry folks, but I need to keep the threads separate to keep my
  24. sanity [at least whatever remains of it.... ;-)]
  25.  
  26. On Fri, 1 Nov 1996 12:11:37 +0100 (MET), Martin J Duerst wrote:
  27.  
  28. >When going from ASCII to UTF-8, there are some new problems.
  29. >For ASCII, the general assumption is that only those charcters
  30. >that need escaping are actually escaped, and therefore that
  31. >escaping, e.g. for "/" or whatever, shouldn't be undone.
  32. >The above is not exactly true, indeed the "~" is often escaped
  33. >as %7E in Europe because it is difficult to type on European
  34. >keyboards, but still I assume there are a lot of tools around
  35. >working on URLs in general that work along the rule "if ASCII
  36. >is escaped, don't remove the escaping, because this is a special
  37. >character.
  38. >Now for UTF-8, things are quite different. 8-bit bytes will
  39. >on many occasions be escaped because it may be difficult to
  40. >represent them otherwise. Having some character beyond ASCII
  41. >represented with %HH (usually %HH%HH or %HH%HH%HH) can in no
  42. >way imply that this is a special character.
  43. >This means that any tools dealing with URNs in general will
  44. >have no clue about where to keep the escaping, and where
  45. >to remove it. A very exact knowledge of each NSS syntax
  46. >would be needed.
  47.  
  48. My brain hurts, but I think I finally understand the issue.  Allow me to
  49. restate it to see if I'm right:
  50.  
  51. The problem you are talking about arrises if the reserved character has
  52. a UTF-8 representation of more than 1 octet.  Then, if we use %encoding
  53. to represent the character in a literal use, there is no way of determining
  54. from the URN whether the character is being used as a literal character
  55. or not. 
  56.  
  57. I'll save a discussion of potential solution directions to this until I'm sure
  58. I understand the issue.
  59.  
  60. Ryan
  61.